home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / Documents / CERT / CA-89:03.telnet.breakin.warning < prev    next >
Text File  |  1996-02-15  |  5KB  |  104 lines
  1.  
  2. CA-89:03
  3.                                  CERT Advisory
  4.                                 August 16, 1989
  5.                             Telnet Breakin Warning
  6.  
  7. ----------------------------------------------------------------------------
  8.  
  9. Many computers connected to the Internet have recently experienced
  10. unauthorized system activity.  Investigation shows that the activity
  11. has occurred for several months and is spreading.  Several UNIX
  12. computers have had their "telnet" programs illicitly replaced with
  13. versions of "telnet" which log outgoing login sessions (including
  14. usernames and passwords to remote systems).  It appears that access
  15. has been gained to many of the machines which have appeared in some of
  16. these session logs.  (As a first step, frequent telnet users should
  17. change their passwords immediately.)  While there is no cause for
  18. panic, there are a number of things that system administrators can do
  19. to detect whether the security on their machines has been compromised
  20. using this approach and to tighten security on their systems where
  21. necessary.  At a minimum, all UNIX site administrators should do the
  22. following:
  23.  
  24. o Test telnet for unauthorized changes by using the UNIX "strings"
  25.   command to search for path/filenames of possible log files.  Affected
  26.   sites have noticed that their telnet programs were logging information
  27.   in user accounts under directory names such as "..." and ".mail".
  28.  
  29. In general, we suggest that site administrators be attentive to
  30. configuration management issues.  These include the following:
  31.  
  32.  
  33. o Test authenticity of critical programs - Any program with access to
  34.   the network (e.g., the TCP/IP suite) or with access to usernames and
  35.   passwords should be periodically tested for unauthorized changes.
  36.   Such a test can be done by comparing checksums of on-line copies of
  37.   these programs to checksums of original copies.  (Checksums can be
  38.   calculated with the UNIX "sum" command.)  Alternatively, these
  39.   programs can be periodically reloaded from original tapes.
  40.  
  41. o Privileged programs - Programs that grant privileges to users (e.g.,
  42.   setuid root programs/shells in UNIX) can be exploited to gain
  43.   unrestricted access to systems.  System administrators should watch
  44.   for such programs being placed in places such as /tmp and /usr/tmp (on
  45.   UNIX systems).  A common malicious practice is to place a setuid shell
  46.   (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  47.   any user can gain privileged system access.
  48.  
  49. o Monitor system logs - System access logs should be periodically
  50.   scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  51.   system activity.
  52.  
  53. o Terminal servers - Terminal servers with unrestricted network access
  54.   (that is, terminal servers which allow users to connect to and from
  55.   any system on the Internet) are frequently used to camouflage network
  56.   connections, making it difficult to track unauthorized activity.
  57.   Most popular terminal servers can be configured to restrict network
  58.   access to and from local hosts.
  59.  
  60. o Passwords - Guest accounts and accounts with trivial passwords
  61.   (e.g., username=password, password=none) are common targets.  System
  62.   administrators should make sure that all accounts are password
  63.   protected and encourage users to use acceptable passwords as well as
  64.   to change their passwords periodically, as a general practice.  For
  65.   more information on passwords, see Federal Information Processing
  66.   Standard Publication (FIPS PUB) 112, available from the National
  67.   Technical Information Service, U.S. Department of Commerce,
  68.   Springfield, VA 22161.
  69.  
  70. o Anonymous file transfer - Unrestricted file transfer access to a
  71.   system can be exploited to obtain sensitive files such as the UNIX
  72.   /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  73.   which requires no username/password authentication) should always be
  74.   configured to run as a non-privileged user and "chroot" to a file
  75.   structure where the remote user cannot transfer the system /etc/passwd
  76.   file.  Anonymous FTP, too, should not allow the remote user to access
  77.   this file, or any other critical system file.  Configuring these
  78.   facilities to "chroot" limits file access to a localized directory
  79.   structure.
  80.  
  81. o Apply fixes - Many of the old "holes" in UNIX have been closed.
  82.   Check with your vendor and install all of the latest fixes.
  83.  
  84.  
  85. If system administrators do discover any unauthorized system activity,
  86. they are urged to contact the Computer Emergency Response Team (CERT).
  87.  
  88. -----------------------------------------------------------------------------
  89.  
  90. Computer Emergency Response Team (CERT)
  91. Software Engineering Institute
  92. Carnegie Mellon University
  93. Pittsburgh, PA 15213-3890
  94.  
  95. Internet: cert@cert.org
  96. Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
  97.            7:30a.m.-6:00p.m. EST, on call for
  98.            emergencies other hours.
  99.  
  100. Past advisories and other information are available for anonymous ftp
  101. from cert.org (192.88.209.5).
  102.  
  103.  
  104.